Дисципліна: Інженерія програмного забезпечення Модуль №1 " Області знань програмної інженерії. Моделі життєвого циклу для розробки програмних систем " Лекція 2 Тема: Загальні вимоги до ПЗ. Керування вимогами Зміст 1. Вступ. Загальна уява про вимоги. Типи вимог 2. Системні вимоги. Документування системних вимог 3. Аналіз реалізує мості. Формування й аналіз вимог. Атестація і огляд вимог. 4. Керування вимогами. 5. Контрольні питання Література 1. Соммервил И. Инженерия программного обеспечения. – М.: И.Д. «Вильямс», 2002. – 624 с. Бабенко Л.П. Основи програмної інженерії. – К.: Т-во «Знання», КОО, 2001. – 269 с. Вступ Проблеми, які доводиться вирішувати фахівцям у процесі створення програмного забезпечення, звичайно дуже складні. Природа цих проблем не завжди ясна, особливо якщо розроблювальна програмна система інноваційна. Зокрема, важко чітко описати ті дії, які повинна виконувати система. Опис функціональних можливостей і обмежень, що накладаються на програмну систему, називається вимогами до цієї системи, а сам процес формування, аналізу, документування й перевірки цих функціональних можливостей і обмежень — розробкою вимог (requirement engineering). Увага концентрується на самих вимогах і способах їхнього опису. Процес розробки вимог загалом описаний у главі 3, а більш докладно освітлений у наступній главі. Термін вимоги (до програмної системи) може трактуватися по-різному. У деяких випадках під вимогами розуміються високорівневі узагальнені твердження про функціональні можливості й обмеження системи. Інша крайня ситуація - деталізований математичний формальний опис системних функцій. Девіс (Davis) [89] так пояснює причини цих розходжень. Якщо компанія хоче виграти контракт на розробку великого програмного проекту, вона змушена, поки рішення не прийняте, представляти вимоги в самому узагальненому виді, щоб, з одного боку, задовольнити вимоги замовника, а з іншого боку - мати можливість для маневру при конкуренції з іншими компаніями-розроблювачами. Після того як контракт виграний, компанія повинна представити замовникові більше докладний опис системи із вказівкою всіх виконуваних нею функцій. В обох ситуаціях надаються документи, які називаються документованими вимогами до системи. Деякі проблеми, що виникають у процесі розробки вимог, породжені відсутністю чіткого розуміння розходження між цими різними рівнями вимог. Щоб розрізнити вимоги різних рівнів, тут використовуються терміни користувальницькі вимоги (user requirement) для позначення високорівневих узагальнених вимог і системні вимоги (system requirement) для деталізованого опису виконуваних системою функцій. Крім вимог цих двох рівнів, застосовується ще більш деталізований опис системи — проектна системна специфікація (software design specification), що може служити мостом між етапом розробки вимог і етапом проектування системи. Три перерахованих види вимог можна визначити в такий спосіб. Користувальницькі вимоги — опис природною мовою функцій (плюс пояснювальні діаграми), виконуваних системою, і обмежень, що накладаються на неї. Системні вимоги — деталізований опис системних функцій і обмежень, що іноді називають функціональною специфікацією. Вона є основою для висновку контракту між покупцем системи й розроблювачами ПО. Проектна системна специфікація — узагальнений опис структури програмної системи, що буде основою для більше деталізованого проектування системи й наступної реалізації. Ця специфікація доповнює й деталізує специфікацію системних вимог. Розходження між користувальницькими й системними вимогами показані в прикладі, представленому в табл. 5.1. Тут показано, як користувальницькі вимоги можуть бути перетворені в системні. Таблиця 5.1. Користувальницькі й системні вимоги Користувальницькі вимоги  1. ПЗ повинне надати засіб доступу до зовнішніх файлів, створеним в інших програмах.  Специфікація системних вимог  1.1. Користувач повинен мати можливість визначати тип зовнішніх файлів.  1.2. Для кожного типу зовнішнього файлу повинне бути відпо...